Bugs found by using ffxtool_v03.exe

-----------------------------------

ffxtool_V03 crash on
1114.c1
1210.c1
1215.c1
1216.c1
1221.c1
3007.c1

Posible bad extract ffxtool_V03 
2998
0275

-----------------------------------
Decompressing small files extract bad data (data corruption)
 -> use ffxdecode 0.3k
Compression dont add 'compression end' char, can cause game crash
 -> add zeroend manually, or with ffxlba
Compression sometimes bad at end of result file, can cause game crash
 (decompression exceed file size limit ("trailing" data at decode) (it compress 1 more byte at end for LZSS?))
 i.e 3738.map (crash), 4 bytes at end "40150000",
    compressed as '024015'8008', which is decompressed as 5 bytes "4015000000"
    (originaly compressed as "0440150000")
    (FFX seems ignore "filesize" of compressed file, ffxtool skips trailing data after filesize)
 -> manually change to correct compresion (change to "uncompressed")
    or add data to end of uncompressed file before compression (data which will be uncompressed or RLE)

-----------------------------------
Short:
ffxtool_v03.exe dont add 'end compression data' char to end of file
it can cause game to crash
??? becouse game decompress files until 'end compression data' char
 -> overwrite all and break data?
(note: ffxtool/ffxdecode dont crash on trailing data or without compression end, uncompress correctly
        -> it ends on 'end' and on decompressed filesize)

Why it sometimes crash:
filesizes are stored div8
if "Size mod 8" != 0 -> padding zeros -> 'end compression' char exist
if "Size mod 8" == 0 -> no padding    -> behind compressed file can be random data
=> can continue decompress and crash, if random data are not zeros....
(no checking decompressed file size?)


Some tests:
Input:
1223, 1222, 1206, 1112)
Original compressed files seems have zeros on end
(if it is part of data or actual 'end compression data' not always clear)
Tests:
Removing zeros from end and decompress with ffxdecode/ffxtool produce same result as with zeros
ffxdecode logs shows that zero are only used as 'end compression data'

(-> zeros on end are not significant for ffxdecode/ffxtool -> padding or 'end compression data')
   ... or there is some 'cleared buffer')

--------------------------------------------
Puvodni zkoumani:
-----------------

Aktualni progres zkoumani zahady
Aktualni odhad
Vinik:
 - ffxtool_v03.exe - externi nastroj na kompresi
Duvod:
 - ffxtool pri kompresi nepridava znacku 'konec'
 ? hra rozbaluje soubory dokud nenarazi na znacku 'konec' (i kdyz by mohla skoncit driv?!)
Proc se to tak asi chova:
 - velikosti souboru jsou ukladany deleno 8
   (tj. soubor ma 800 -> ulozi se velikost 100, 801 az 807 -> 101, atd...
        kdyz hra nacita data, precte velikost -> 100->800, 101->808)
 - vetsinou neni velikost souboru presne delitelna 8,
   takze se soucasti souboru stanou data za souborem = nuly, a ty jsou stejne jako znacka 'konec'
 - pokud je ovsem soubor delitelny 8, a hra nacte presnou velikost, nemusi existovat znacka 'konec' (jsou tam nahodna data)
   -> hra muze rozbalovat soubor donekonecna -> dostane se mimo svuj prostor -> prepise vsechno -> spadne

Proto se pri zmene 'zmensovani souboru' a 'zmene textu' chovala hra ruzne.
Jednou vysledny soubor delitelny 8 byl, jindy nebyl....
Kdyz byl.. hra spadla...
Kdyz jsem pridal nulu nakonec tech komprimovanych souboru co puvodne spadli, po importu nespadli:P

Reseni:
pridam do importu souboru zvetseni komprimovanych souboru a 1 byte:P
(workaround pro ffxtool)
nebo
udelam vlastni komprimacni nastroj:P
(prvni varianta bude 20x rychlejsi, na druhe se mozna bude pracovat pozdeji:P)

Zamysleni:
je divne ze to postihuje jen tenhle soubor, mozna toho bude vice,
nebo jen za timhle jsou nahodna data a ne "nuly".
